A storage system is a computer that provides storage service relating to the organization of information on writeable persistent storage devices, such as memories, tapes or disks. The storage system is commonly deployed within a storage area network (SAN) or a network attached storage (NAS) environment. When used within a NAS environment, the storage system may be embodied as a file server including an operating system that implements a file system to logically organize the information as a hierarchical structure of directories and files on, e.g. the disks. Each “on-disk” file may be implemented as a set of data structures, e.g., disk blocks, configured to store information, such as the actual data for the file. A directory, on the other hand, may be implemented as a specially formatted file in which information about other files and directories are stored.
The storage system may be further configured to operate according to a client/server model of information delivery to thereby allow many client systems (clients) to access shared resources, such as files, stored on the storage system. Sharing of files is a hallmark of a NAS system, which is enabled because of semantic level of access to files and file systems. Storage of information on a NAS system is typically deployed over a computer network comprising of a geographically distributed collection of interconnected communication links, such as Ethernet, that allow clients to remotely access the information (files) on the file server. The clients typically communicate with the storage system by exchanging discrete frames or packets of data according to pre-defined protocols, such as the Transmission Control Protocol/Internet Protocol (TCP/IP).
In the client/server model, the client may comprise an application executing on a computer that “connects” to the storage system over a computer network, such as a point-to-point link, shared local area network, wide area network or virtual private network implemented over a public network, such as the Internet. NAS systems generally utilize file-based access protocols; therefore, each client may request the services of the storage system by issuing file system protocol messages (in the form of packets) to the file system over the network. By supporting a plurality of file system protocols, such as the conventional Common Internet File System (CIFS), the Network File System (NFS) and the Direct Access File System (DAFS) protocols, the utility of the storage system may be enhanced for networking clients.
A SAN is a high-speed network that enables establishment of direct connections between a storage system and its storage devices. The SAN may thus be viewed as an extension to a storage bus and, as such, an operating system of the storage system enables access to stored information using block-based access protocols over the “extended bus”. In this context, the extended bus is typically embodied as Fibre Channel (FC) or Ethernet media adapted to operate with block access protocols, such as Small Computer Systems Interface (SCSI) protocol encapsulation over FC (FCP) or TCP/IP/Ethernet (iSCSI). A SAN arrangement or deployment allows decoupling of storage from the storage system, such as an application server, and some level of storage sharing at the application server level. There are, however, environments wherein a SAN is dedicated to a single server. When used within a SAN environment, the storage system may be embodied as a storage appliance that manages data access to a set of disks using one or more block-based protocols, such as SCSI embedded in Fibre Channel (FCP). One example of a SAN arrangement, including a multi-protocol storage appliance suitable for use in the SAN, is described in U.S. Pat. No. 7,873,700, issued on Jan. 18, 2011, entitled MULTI-PROTOCOL STORAGE APPLIANCE THAT PROVIDES INTEGRATED SUPPORT FOR FILE AND BLOCK ACCESS PROTOCOLS, by Brian Pawlowski, et al.
It is advantageous for the services and data provided by a storage system, such as a storage appliance to be available for access to the greatest degree possible. Accordingly, some storage systems provide a plurality of storage appliances in a cluster, with a property that when a first storage appliance fails, the second storage appliance (“partner”) is available to take over and provide the services and the data otherwise provided by the first storage appliance. When the first storage appliance fails, the second partner storage appliance in the cluster assumes the tasks of processing and handling any data access requests normally processed by the first storage appliance. One such example of a storage appliance cluster configuration is described in U.S. Pat. No. 7,260,737, issued on Aug. 21, 2007, entitled SYSTEM AND METHOD FOR TRANSPORT-LEVEL FAILOVER OF FCP DEVICES IN A CLUSTER, by Arthur F. Lent, et al. An administrator may desire to take a storage appliance offline for a variety of reasons including, for example, to upgrade hardware, etc. In such situations, it may be advantageous to perform a user-initiated takeover operation, as opposed to a failover operation. After the takeover operation is complete, the storage appliance's data will be serviced by its partner until a giveback operation is performed.
In certain known storage appliance cluster configurations, the transport medium used for communication between clients and the cluster is Fibre Channel (FC) cabling utilizing the FCP protocol (SCSI embedded in FC) for transporting data. In SCSI terminology, clients operating in a SAN environment are initiators that initiate requests and commands for data. The multi-protocol storage appliance is thus a target configured to respond to the requests issued by the initiators in accordance with a request/response protocol. According to the FC protocol, initiators and targets have three unique identifiers, a Node Name, a Port Name and a Device Identifier. The Node Name and Port Name are worldwide unique, e.g. World Wide Node Name (WWNN) and World Wide Port Name (WWPN). A Device Identifier unique within a given FC switching fabric and is assigned dynamically to the FC port by a FC switch coupled thereto.
In conventional failover techniques involving clusters of storage appliances, each is storage appliance in the cluster maintains two physical FC ports, namely an A port and a B port. The A port is utilized for processing and handling data access requests directed to the storage appliance. The B port typically is in a standby mode; when a failover situation occurs, the B port is activated and “assumes the identity” of its failed partner storage appliance. At that point, the B port functions as a FC target to receive and handle data access requests directed to the failed storage appliance. In this way, the surviving storage appliance may process requests directed to both the storage appliance and its failed partner storage appliance. Such a conventional FC failover is further described in the above-referenced U.S. Pat. No. 7,260,737, issued on Aug. 21, 2007, entitled SYSTEM AND METHOD FOR TRANSPORT-LEVEL FAILOVER OF FCP DEVICES IN A CLUSTER.
Specifically, the B port of the “surviving” storage appliance upon assuming the identity of its failed partner storage appliance, services data access requests direct to a WWNN and a WWPN of the partner. For many client operating systems, this is sufficient to permit clients to transparently access the surviving storage appliance as if it were the failed storage appliance. That is, the data access requests directed to these unique network address identifiers of the failed storage appliance are received and processed by the surviving storage appliance. Although it may appear to the clients as if the failed storage appliance was momentarily disconnected and reconnected to the network, data operations associated with the data access requests continue to be processed.
FIG. 1 is a schematic block diagram of an exemplary storage system network environment 100. The environment 100 comprises a network cloud 102 coupled to a client 104. The client 104 may be a general-purpose computer, such as a PC or a workstation, or a special-purpose computer, such as an application server, configured to execute applications over an operating system that includes block access protocols. A storage system cluster 130, comprising Red Storage System 300A and Blue Storage System 300B, is also connected to the cloud 102. These storage systems, are illustratively embodied as storage appliances configured to control storage of and access to interconnected storage devices, such as disks residing on disk shelves 112 and 114.
In the illustrated example, Red Storage Appliance 300A is connected to Red Disk Shelf 112 by the A port 116. The Red Storage System 300A also accesses Blue Disk Shelf 114 via the B port 118. Likewise, Blue Storage Appliance 300B accesses Blue Disk Shelf 114 via A port 120 and Red Disk Shelf 112 through counterpart B port 122. Thus each disk shelf in the cluster is accessible to each storage appliance, thereby providing redundant data paths in the event of a failover. It should be noted that the Red and Blue disk shelves are shown directly connected to the storage appliances 300 for illustrative purposes only.
Connecting the Red and Blue Storage Appliances 300A, B is a cluster interconnect 110, which provides a direct communication link between the two storage appliances. The cluster interconnect 110 can be of any suitable communication medium, including, for example, an Ethernet connection or a FC data link.
During normal cluster operation, the storage system that is connected to a disk shelf via the disk shelf's primary port is the “owner” of the disk shelf and is primarily responsible for servicing data requests directed to blocks on volumes contained on that disk shelf. Thus, in this example, the Red storage appliance 300A owns the Red Disk Shelf 112 and is primarily responsible for servicing data access requests for blocks contained on that disk shelf. Similarly, the Blue storage appliance 300B is primarily responsible for the Blue disk shelf 114. When operating as storage appliance cluster 130, each storage appliance 300 is typically configured to take over and assume data handling capabilities for the other disk shelf in the cluster 130.
SCSI Enclosure Services (SES) provides a command set for obtaining environmental information relating to disks connected to a disk shelf, such as disk shelves 112, 114. SCSI Enclosure Services is defined in SCSI Enclosure Services-2 (SES-2), published by Committee T-10 on 22 Jul. 2004, the contents of which are hereby incorporated by reference. In some SES environments, each disk shelf contains two disk slots that are designated as SES slots. A storage system that owns a disk in an SES slot (a “SES disk”) is a master of that shelf (a “SES master”) and is able to retrieve SES environmental information relating to the entire shelf and modify data including, for example, setting a light emitting diode (LED) to signify the status of one or more disks. The use of SES disks in a two storage system cluster environment is advantageous as each of the storage systems typically is the master of a particular shelf. In the example of FIG. 1, the Red Storage Appliance is the SES master of Red Disk Shelf 112, whereas the Blue Storage Appliance is the SES master of the Blue Disk Shelf 114. This results from the Red Storage Appliance typically owning all disks in the Red Disk Shelf and the Blue storage appliance owning all disks in the Blue disk shelf. During a failover situation, when a storage appliance has taken ownership of a disk, the state of being the SES master of the shelf also passes with the ownership of the SES disks. For example, if the Red Storage Appliance fails and the Blue Storage Appliance takes ownership of the disks on Red Disk Shelf 112, the Blue Storage Appliance would become the SES master of the Red Disk Shelf 112.
A noted disadvantage arises in storage system environments having more than two storage systems. In such an environment, a storage system may own a non-SES disk on a disk shelf and not own either of the SES disks on the shelf. As such, the storage system lacks the capability to obtain SES information or to set certain environmental variables, e.g., setting a disk failure LED for the disk that it owns.